Quality of Experience by the user when using applications through a network is dependent on the type of application, and its behavior in dealing with packet loss, delay, jitter, and bandwidth variations introduced by the network. For some applications such as Voice and Video, prior-art methods define computing MOS (Mean Opinion Scores) as a measure of user's quality of experience using client side applications or estimating the MOS scores based on what client reports via control protocols such as RTCP and RTCP XR. For example, using RTCP, the client reports packet loss, delay, jitter and other parameters. These parameters can be used in conjunction with the E-model to compute a transmission rating-factor, “R”, and corresponding MOS score. An application server or a monitoring device that monitors RTCP could estimate video or voice MOS scores for such applications.
However some network deployments do not enable the use of RTCP, or RTCP streams may be encrypted, thus preventing transit network devices from estimating the MOS Scores. If RTCP streams are encrypted, the server that terminates the RTCP stream could estimate the MOS score; however, an intermediate monitoring device that taps application flows could not decode the encrypted streams, and thus could not estimate the MOS scores.
Additionally, MOS scores for Voice and Video in the prior art methods are defined for active call (when the service is active), and does not include other parameters, such as how long it took for a user to establish a call, or if a call is dropped during the middle and re-established. Also, MOS Scores for Video measure the Mean Opinion Score in the Receiver (Client) at the MPEG/Video content level, and do not estimate the quality of delivery by the transit network. 3GPP standards define network performance KPIs, such as, “Accessibility, Retainability, Availability, Integrity and Mobility” that characterizes the network goodness based on the data from network elements, such as Base Station, NodeB, eNB, RNC, etc. Per the standards, the network elements maintain performance metrics of key functional components, such as IP Throughput, RRC Success Rate, RAB Establishment success rate, etc., and periodically report them to an OSS. The OSS system computes the 3GPP defined Network functional KPIs, such as Accessibility and Retainability from the received performance data. For example, 3GPP 32.814 defines Accessibility to be computed from the RAB Establishment Success Rate and RRC Success Rate.
However these metrics do not facilitate characterizing per user QOE; per user QOE is dependent on the type of service/application that the user is using; some applications/services are more sensitive to delay and others more dependent on bandwidth, packet loss etc. In wireless access networks, the delay and capacity are highly varying due to coverage, capacity, interference, and congestion at one or more aggregation points. Therefore, the delay, jitter, and packet loss experienced by each direction of stream varies significantly.
A transit network device that transparently monitors application flows and estimates Quality of Experience by each flow, and rolls up estimated QOE per service, per user and per aggregation points such as a Sector, NodeB/eNodeB/RNC, Aggregation Router, Media Gateway etc., and reports QOE degradation would benefit network operators significantly. This would allow network operators to move services to alternate networks, initiate network tuning via 3GPP/SON (Self Optimizing Network) methods, identify problem locations, and characterize network goodness as a function of “Happy Users” for these services; all of which serve to maximize user QOE and reduce churn.
Thus, a method and device that enables this transparent monitoring of application flows and estimates QoE per flow, per serve, per user and per aggregation points would be beneficial.